The following meanings for the abbreviations used in this specification apply:    3GPP: 3rd generation partnership project    AAA: Authentication, Authorization, Accounting    AF: Application Function    AN: Access network    AVP: Attribute Value Pair    CCR: Credit Control Request    CCA: Credit Control Answer    DDS: Dedicated Diameter Session for IP-CAN bearer/session    GGSN: Gateway GPRS Support Node    GTP: GPRS Tunnelling Protocol    Gx: Name of interface between PCEF and PCRF    HSS: Home Subscriber Server    IMS: IP multimedia subsystem    IP: Internet Protocol    IP-CAN: Internet Protocol Connectivity Access Network    LTE: Long Term Evolution    MME: Mobility Management Entity    QCI: QoS Class Identifier    QoS: Quality of Service    PCC: Policy and Charging Control    PCEF: Policy and Charging Enforcement Function    PCRF: Policy and Charging Rule Function    PDN: Packet Domain Network    P-GW: PDN Gateway    RAR: Re-Authorization Request    RAA: Re-Authorization Answer    RAT: Radio Access Technology    SGSN: Serving GPRS Support Node    S-GW: Serving Gateway    SIP: Session Initiation Protocol
Examples of the present invention are related to the Gx interface, which is part of the 3GPP/LTE PCC (policy and charging control) architecture, as shown in FIG. 8 (corresponding to FIG. 5.1.1 from 3GPP 23.203).
In particular, reference number 1 denotes a subscription profile repository (SPR) in which subscription profiles are stored. Reference number 2 denotes an application function (AF). Reference number 3 denotes a policy and charging rules function (PCRF). The PCRF is a functional element that encompasses policy control decision and flow based on charging control functionalities. Reference number 4 denotes a bearer binding and event reporting function (BBERF). The BBERF is a functional element located in the serving gateway (S-GW) and provides control over the user plane traffic handling and other functionalities, such as bearer handling etc. Reference number 5 denotes an online charging system (OCS), which also comprises a service data flow based credit control 51. Furthermore, reference number 6 denotes a gateway, in which a policy and charging enforcement function (PCEF) 61 is provided. The PCEF encompasses policy enforcement and flow based charging functionalities. In particular, it provides control over the user plane traffic handling at the gateway and provides service data flow detection accounting as well as online and offline charging interactions. Reference number 7 denotes an offline charging system (OFCS).
Between the elements described above, several reference points are defined. Between the SPR and the PCRF the Sp reference point is defined, via which the PCRF my obtain information such as subscriber and service related data. Between the AF 2 and the PCRF, the Rx reference point is defined, via which the PCRF my obtain information such as session, media and subscriber related information. Between the PCRF and the BBERF, the Gxx reference point is defined, via which the PCRF may obtain bearer related data. Between the PCRF and PCEF the Gx reference point is defined, via which the PCRF may obtain information regarding IP-CAN bearer attributes, request type, subscriber related information and the like from the PCEF. Between the service data flow based credit control 51 of the OCS 5 and the PCEF, the Gy reference point is defined, and between the PCRF and the OFCS, the reference point Gz is defined.
Embodiments of the present invention aim to improve the performance of Gx interface by reducing the amount of signalling performed in the Gx interface. Gx interface is based on Diameter Gx application protocol, which is fairly heavy protocol.
In an example PCRF product, one cluster could handle 4000 messages per second and it could be able to handle 600000 concurrent sessions. An example gateway could have 5 million concurrent sessions. This means that at least 9 PCRF products are required to have 5 million concurrent sessions of single gateway. In past, operators have not been willing to invest lots of money to PCC. On the other hand, most operators are still interested in PCC architecture and they would most likely buy Gx interface provided there is a vendor who can provide cost efficient yet fully functional Gx interface.
In prior art, there are already some solutions, which can be used to reduce the amount of signalling in Gx interface and thus reduce the cost of the Gx interface.
For example, it is possible to locally define policies in the gateway. It is also possible to define the detailed policy rules in the gateway and refer to those policy rules in the Gx interface using rule identifiers such as rule base identifiers. This solution reduces the amount of parameters exchanged over the Gx interface, but it does not reduce the amount of signalling itself. Even if there are locally defined policy rules in the gateway, gateway still needs to request for PCC rules when IP-CAN bearer is established. Thus, this optimization does not actually reduce the amount of signalling or number of the concurrent Gx sessions, so it is not possible to reduce the number of PCRF nodes in the PCC infrastructure.
PCRF may provision event triggers to PCEF. As specified in 3GPP 29.212, section 4.5.3, an event trigger may be used to determine which IP-CAN session modification or specific event causes the PCEF to re-request PCC rules. Although event trigger reporting from PCEF to PCRF can apply for an IP CAN session or bearer depending on the particular event, provisioning of event triggers will be done at session level.
It is possible to disable all event triggers and thus prevent all signalling related to IP-CAN modifications. If PCRF does not get any information about the IP-CAN bearer modifications, it cannot update PCC rules based on modification to IP-CAN bearer. For some modifications, this may not be an issue, if PCC rules define how policy should be changed when e.g. roaming status or RAT changes. On the other hand, disabling all event triggers would also seriously limit the PCRF capability to control the QoS, because PCRF cannot authorize QoS modifications and it would not know what the currently applied QoS is for IP-CAN bearers. Thus, it is not feasible to disable all the event triggers. Furthermore, this solution does not reduce the amount of concurrent Gx sessions, because Gx sessions still have to be maintained until the IP-CAN bearer is terminated.